Деплой готового SaaS на Next.js 14 + Supabase + Railway (продакшн под ключ)

Требуется развернуть в продакшн готовое SaaS-приложение. Код написан и находится в приватном репозитории GitHub (126 файлов), новая разработка не требуется — нужен деплой, настройка инфраструктуры и доведение до стабильно работающего состояния. Стек Next.js 14 (App Router, JavaScript без TypeScript), Supabase (Postgres + Auth), BullMQ + Redis (Upstash), Playwright в Docker, Paddle (merchant of record), Resend, Sentry. Что нужно сделать 1. Supabase: создать проект, применить готовую схему из репозитория (supabase/schema.sql), включить Email OTP авторизацию, проверить RLS-политики. 2. Vercel: импортировать репозиторий, настроить переменные окружения (14 шт., полный список в ТЗ), подключить домен и SSL. 3. Railway: развернуть два сервиса на готовом Dockerfile — постоянный воркер очереди и cron-сервис ежемесячных задач. Проверить работу Playwright/Chromium в контейнере. 4. Upstash Redis, Resend (верификация домена, SPF/DKIM), Sentry — подключение и проверка. 5. Paddle: интеграция чекаута и вебхуков, тесты в sandbox (создание и отмена подписки, неуспешный платёж), затем переключение на боевой аккаунт. 6. Исправить три известные проблемы репозитория (детально описаны в ТЗ): отсутствует package-lock.json при использовании npm ci в Dockerfile; в 19 файлах остались ссылки на старый домен; установка Chromium в Dockerfile идёт с «|| true» и может тихо не сработать. 7. Прогнать калибровочный скрипт и тесты из репозитория, вручную проверить 10 отчётов. 8. Сдать краткий runbook (2–4 страницы): как выкатить обновление, где смотреть логи, что делать при типовых сбоях. Критерии приёмки • Полный путь работает end-to-end на боевом домене: скан → отчёт → письмо → оплата тестовой картой Paddle. • Вебхук создаёт подписку; отмена в Paddle синхронизирует статус. • Публичные страницы индексируемы и присутствуют в sitemap. • Sentry получает тестовые ошибки из веб-приложения и из воркера. • Cron ставит задачи в очередь, воркер их разбирает. • Ни одного упоминания старого домена в продакшн-сборке. Порядок работы и оплаты Работа разбита на этапы. По каждому этапу: исполнитель делает — заказчик проверяет по критериям — оплата этапа. Предоплаты нет; оплата производится за каждый принятый этап. Этап Содержание Что проверяем при приёмке 1 Supabase, Redis, внешние сервисы (пункты 1 и 4) Схема применена, авторизация работает, ключи выданы заказчику 2 Vercel, домен, исправление проблем репозитория (пункты 2 и 6) Сайт открывается на боевом домене, сборка проходит, старый домен нигде не упоминается 3 Railway: воркер и cron (пункт 3) Тестовый скан выполняется до конца, cron ставит задачи в очередь 4 Paddle: sandbox и боевой режим (пункт 5) Тестовая оплата проходит, вебхуки создают и отменяют подписку 5 Калибровка, тесты, runbook (пункты 7 и 8) Тесты зелёные, отчёты корректны, документация передана Разбивку на этапы и стоимость каждого предлагает исполнитель в отклике — приведённая таблица является ориентиром и может быть уточнена. Условия • Все доступы (Vercel, Supabase, Railway, Paddle, домен) оформляются на аккаунты заказчика, исполнитель приглашается участником. Код, инфраструктура и данные принадлежат заказчику. • Подробное ТЗ (5 страниц) с полным списком переменных окружения и описанием известных проблем высылаю в личные сообщения по запросу. • Ключи внешних API и оплату сервисов обеспечивает заказчик. • Коммуникация: мессенджер и один короткий созвон в неделю. Язык: русский или английский. Не входит в задачу Разработка новых функций, изменение продуктовой логики, дизайн, тексты интерфейса, маркетинг, наполнение контентом, работа с клиентами. Прошу указать в отклике 1. Опыт с Next.js App Router, Supabase RLS, BullMQ, Playwright в Docker, вебхуками Paddle — с примерами проектов. 2. Предлагаемую разбивку на этапы со сроком и стоимостью каждого. 3. Какие риски вы видите по описанию выше и что может занять больше времени, чем кажется. Отклики без ответов на эти три вопроса не рассматриваю.